-
Notifications
You must be signed in to change notification settings - Fork 993
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(swarm): remove deprecated inject calls #3264
Conversation
swarm-derive: remove inject methods from derive macro.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks for following up on that!
I think we can simplify some of this a bit. Let me know if you need more input :)
swarm/src/handler/either.rs
Outdated
#[allow(deprecated)] | ||
handler.inject_fully_negotiated_outbound(output, info) | ||
(Either::Left(handler), EitherOutput::First(output), Either::Left(info)) => { | ||
handler.on_connection_event(ConnectionEvent::FullyNegotiatedOutbound( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems weird that we need to match on the event here (line 174). I think it would be better if we added a
impl ConnectionEvent<EitherOutput, EitherOutput, Either, Either> { }
block where we map the entire event into a Either<ConnectionEvent, ConnectionEvent>
so you can directly dispatch the event to the left or the right handler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that would be great. I tried:
impl<'a, R, L>
ConnectionEvent<
'a,
EitherUpgrade<SendWrapper<L::InboundProtocol>, SendWrapper<R::InboundProtocol>>,
EitherUpgrade<SendWrapper<L::OutboundProtocol>, SendWrapper<R::OutboundProtocol>>,
Either<L::InboundOpenInfo, R::InboundOpenInfo>,
Either<L::OutboundOpenInfo, R::OutboundOpenInfo>,
>
where
L: ConnectionHandler,
R: ConnectionHandler,
{}
but get that L
and R
are not constrained. I wonder if #3085 (comment) would have changed that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking something like e3480d2. It doesn't compile yet but maybe you can make it work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the lead Thomas, managed to make it work. Used Either::Left
for AddressChange
instead of the Result
as it seemed more semantically accurate in the sense that it's not err, it just doesn't matter if it's either Left
or Right
for that variant, cause when matching on on_connection_event
we still have the Either::Right
. Ptal and see if you agree.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the lead Thomas, managed to make it work. Used
Either::Left
forAddressChange
instead of theResult
as it seemed more semantically accurate in the sense that it's not err, it just doesn't matter if it's eitherLeft
orRight
for that variant, cause when matching onon_connection_event
we still have theEither::Right
. Ptal and see if you agree.
Yeah I wasn't sure about that one. I think one could argue it is an error because we couldn't unambiguously transpose it. Can we make it work with Result
or is moving to Either::Left
essential?
Alternatively, we could wrap it in another Either
but that is a bit weird. If possible, I'd prefer the Result
return type and some documentation on why it is necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no you are right, documenting it informing that an Err
can be because AddressChange
isn't transposable makes sense to me, updated it :)
swarm/src/handler/select.rs
Outdated
@@ -165,60 +169,72 @@ where | |||
>, | |||
) { | |||
match (info, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, I think we could make use of the same mapping function from above here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed, see if that's what you were expecting Thomas
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for tackling this.
fn on_swarm_event(&mut self, _event: FromSwarm<Self::ConnectionHandler>) {} | ||
fn on_swarm_event(&mut self, event: FromSwarm<Self::ConnectionHandler>); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@@ -367,35 +366,47 @@ where | |||
TInboundSubstreamHandler::upgrade(()) | |||
} | |||
|
|||
fn inject_fully_negotiated_inbound( | |||
fn on_connection_event( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this change is breaking, right? Thus advocating for no changelog.
On a related note, shouldn't our CI have caught this? Shouldn't this have generated a deprecation warning and thus shouldn't CI have failed? Can you investigate this @jxs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah this isn't a breaking change afaik, as they are only called by the Behaviour
On a related note, shouldn't our CI have caught this? Shouldn't this have generated a deprecation warning and thus shouldn't CI have failed?
good point, cargo
doesn't trigger deprecation warning on the implementation, only on the invocation IRC, do we have any code triggering calls to the methods?
swarm/src/handler/either.rs
Outdated
#[allow(deprecated)] | ||
handler.inject_fully_negotiated_outbound(output, info) | ||
(Either::Left(handler), EitherOutput::First(output), Either::Left(info)) => { | ||
handler.on_connection_event(ConnectionEvent::FullyNegotiatedOutbound( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, that would be great. I tried:
impl<'a, R, L>
ConnectionEvent<
'a,
EitherUpgrade<SendWrapper<L::InboundProtocol>, SendWrapper<R::InboundProtocol>>,
EitherUpgrade<SendWrapper<L::OutboundProtocol>, SendWrapper<R::OutboundProtocol>>,
Either<L::InboundOpenInfo, R::InboundOpenInfo>,
Either<L::OutboundOpenInfo, R::OutboundOpenInfo>,
>
where
L: ConnectionHandler,
R: ConnectionHandler,
{}
but get that L
and R
are not constrained. I wonder if #3085 (comment) would have changed that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the follow-ups.
@@ -367,35 +366,47 @@ where | |||
TInboundSubstreamHandler::upgrade(()) | |||
} | |||
|
|||
fn inject_fully_negotiated_inbound( | |||
fn on_connection_event( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this change is breaking, right? Thus advocating for no changelog.
On a related note, shouldn't our CI have caught this? Shouldn't this have generated a deprecation warning and thus shouldn't CI have failed? Can you investigate this @jxs?
- Replace `NetworkBehaviour` Derive macro deprecated `inject_*` method implementations | ||
with the new `on_swarm_event` and `on_connection_handler_event`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This entry was previously mistakenly in v0.31.0
, right? I.e. we did not actually move to the on_
methods in swarm-derive
in v0.31.0
as otherwise our non-breaking-change hack would not have worked, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah exactly, thanks for referring this Max.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please trigger mergify once the above discussion with @thomaseizinger is resolved.
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
for ConnectionEvent and DialUpgradeError, to help when matching on them for Either and Select.
S1OOI: Send + 'static, | ||
S2OOI: Send + 'static, | ||
{ | ||
fn transpose(self) -> Either<DialUpgradeError<S1OOI, S1OP>, DialUpgradeError<S2OOI, S2OP>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that you split this out. I actually think it makes sense to split this out for all structs of ConnectionEvent
. Can we reuse this as part of implementing the bigger transpose
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, thanks :D but I did it because in some variants like ListenUpgradeError
or AddressChange
transpose doesn't win us anything as we have to call it for both Select
variants. I updated the code implementing for the variants where it makes sense, ptal Thomas and see if it makes sense to you.
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
for the remaining ConnectionEvents that is useful to implement on.
to Result and document it.
swarm/src/handler/either.rs
Outdated
ConnectionEvent::FullyNegotiatedInbound(FullyNegotiatedInbound { | ||
protocol: EitherOutput::First(protocol), | ||
info: Either::Left(info), | ||
}) => Ok(Either::Left(ConnectionEvent::FullyNegotiatedInbound( | ||
FullyNegotiatedInbound { protocol, info }, | ||
))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ConnectionEvent::FullyNegotiatedInbound(FullyNegotiatedInbound { | |
protocol: EitherOutput::First(protocol), | |
info: Either::Left(info), | |
}) => Ok(Either::Left(ConnectionEvent::FullyNegotiatedInbound( | |
FullyNegotiatedInbound { protocol, info }, | |
))), | |
ConnectionEvent::FullyNegotiatedInbound(inner) => Ok(inner.transpose()), |
Does this work? Or do we have to call .map
on it again or something?
It would be cool if we can express this transpose
function somehow through the smaller ones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't because Select
's implementation uses SelectUpgrade
whereas Either
uses EitherUpgrade
, do you have any idea how can we combine them in transpose
? :P
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can combine them for select and either because those are fundamentally different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, one of them is using EitherOutput
which we need because Either
doesn't implement AsyncRead
+ AsyncWrite
.
See #2650.
This pull request has merge conflicts. Could you please resolve them @jxs? 🙏 |
@thomaseizinger submitted #3307 which started as fork from this one and also addresses some of the conversations here. Can we merge this one and continue there? I can also open an issue to address potential unresolved conversations. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few more comments, overall looks good to me!
swarm/CHANGELOG.md
Outdated
@@ -7,12 +7,18 @@ | |||
|
|||
- Add `estblished_in` to `SwarmEvent::ConnectionEstablished`. See [PR 3134]. | |||
|
|||
- Remove deprecated `inject_*` methods from `NetworkBehaviour` and `ConnectionHandler`. | |||
see [PR 3260]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see [PR 3260]. | |
see [PR 3264]. |
Wrong issue reference :)
swarm/src/handler/either.rs
Outdated
ConnectionEvent::FullyNegotiatedInbound(FullyNegotiatedInbound { | ||
protocol: EitherOutput::First(protocol), | ||
info: Either::Left(info), | ||
}) => Ok(Either::Left(ConnectionEvent::FullyNegotiatedInbound( | ||
FullyNegotiatedInbound { protocol, info }, | ||
))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we can combine them for select and either because those are fundamentally different.
swarm/src/handler/either.rs
Outdated
ConnectionEvent::FullyNegotiatedInbound(FullyNegotiatedInbound { | ||
protocol: EitherOutput::First(protocol), | ||
info: Either::Left(info), | ||
}) => Ok(Either::Left(ConnectionEvent::FullyNegotiatedInbound( | ||
FullyNegotiatedInbound { protocol, info }, | ||
))), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, one of them is using EitherOutput
which we need because Either
doesn't implement AsyncRead
+ AsyncWrite
.
See #2650.
match fully_negotiated_outbound.transpose() { | ||
Either::Left(f) => self | ||
.proto1 | ||
.on_connection_event(ConnectionEvent::FullyNegotiatedOutbound(f)), | ||
Either::Right(f) => self | ||
.proto2 | ||
.on_connection_event(ConnectionEvent::FullyNegotiatedOutbound(f)), | ||
} | ||
} | ||
ConnectionEvent::FullyNegotiatedInbound(fully_negotiated_inbound) => { | ||
self.on_fully_negotiated_inbound(fully_negotiated_inbound) | ||
match fully_negotiated_inbound.transpose() { | ||
Either::Left(f) => self | ||
.proto1 | ||
.on_connection_event(ConnectionEvent::FullyNegotiatedInbound(f)), | ||
Either::Right(f) => self | ||
.proto2 | ||
.on_connection_event(ConnectionEvent::FullyNegotiatedInbound(f)), | ||
} | ||
} | ||
ConnectionEvent::AddressChange(address) => { | ||
#[allow(deprecated)] | ||
self.proto1.inject_address_change(address.new_address); | ||
#[allow(deprecated)] | ||
self.proto2.inject_address_change(address.new_address) | ||
self.proto1 | ||
.on_connection_event(ConnectionEvent::AddressChange(AddressChange { | ||
new_address: address.new_address, | ||
})); | ||
|
||
self.proto2 | ||
.on_connection_event(ConnectionEvent::AddressChange(AddressChange { | ||
new_address: address.new_address, | ||
})); | ||
} | ||
ConnectionEvent::DialUpgradeError(dial_upgrade_error) => { | ||
self.on_dial_upgrade_error(dial_upgrade_error) | ||
match dial_upgrade_error.transpose() { | ||
Either::Left(err) => self | ||
.proto1 | ||
.on_connection_event(ConnectionEvent::DialUpgradeError(err)), | ||
Either::Right(err) => self | ||
.proto2 | ||
.on_connection_event(ConnectionEvent::DialUpgradeError(err)), | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it would be better to do it like this for the either::Handler
as well? i.e. only transpose the inner type instead of the entire event and matching on the tuple.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah you are right Thomas, you had already mentioned before sorry it slipped me. It makes sense cause then we don't need Err
for AddressChange
. Updated ptal!
do it per variant instead of on the ConnectionEvent itself, so that we no longer need the Err on the case of AddressChange.
017641e
to
a6c052d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Nice to see it being a negative diff!
Sorry I missed this on #3264
Description
Finishes work first started with #2832
Notes
review by commit is suggested :)
Links to any relevant issues
Open Questions
Change checklist